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Abstract 


Planning  and  decision  making  for  battle  management  are  difficult  and  time- 
critical  tasks.  To  facilitate  the  study  of  these  cognitive  processes  in  the  labo¬ 
ratory,  an  army  wargame  facility  (WARFAC)  has  been  developed  at  DCIEM. 
This  report  details  the  design  and  implementation  of  an  extension  to  WARFAC, 
an  expert  system  opponent.  This  extension  will  allow  controlled  experiments 
with  a  single  human  subject.  Initial  test  results  are  presented  and  its  possible 
uses  as  a  research  tool  are  outlined. 
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1  Executive  Summary 

Directing  the  control  of  armed  forces  in  battle  is  a  complex  and  time-critical 
task.  It  is  of  considerable  practical  interest  to  understand  the  planning  and 
decision  making  processes  that  are  involved.  One  of  the  means  for  investigat¬ 
ing  human  decision  making  and  the  associated  planning  processes  is  to  devise 
a  simulation  environment  in  which  these  processes  can  be  made  to  occur  and 
thereby  studied.  To  this  end,  an  army  wargame  facility  (WARFAC)  was  devised 
at  DCIEM  through  the  1980’s.  WARFAC  permits  two  players  to  manipulate 
resources  to  accomplish  a  tactical  mission.  As  an  extension  to  WARFAC,  an 
intelligent  computer  opponent  (WFICO)  has  been  developed  to  provide  con¬ 
sistent  opposition  and  thus  simplify  the  task  of  assessing  the  human  player’s 
performance. 

WFICO  was  designed  with  a  dynamic  knowledge  base  and  rules  with  a 
layered  structure  that  models  the  army  command  and  control  hierarchy.  This 
report  details  the  status  of  this  expert  system,  the  expert  system  shell  used  in 
its  development,  and  the  potential  use  of  WFICO  as  a  research  tool. 

Initial  testing  of  WFICO  used  a  smaU  knowledge  base  consisting  of  simple 
rules  governing  combat  and  movement  of  units.  Results  with  this  simple  pro¬ 
totype  demonstrated  that  WFICO  could  respond  reasonably  weU  against  an 
experienced  human  opponent  in  the  defence  of  an  identified  objective  (prevent 
a  bridge  crossing). 

Together  with  WARFAC,  WFICO  provides  an  open  ended  testbed  for  re¬ 
search  in  command  and  control  (C^).  It  can  be  used  to  support  research  in 
the  assessment  of  the  decision  process,  assist  in  C'^  decision  tasks,  or  test 
decision  making  rules. 


2  Introduction 


Directing  the  control  of  armed  forces  in  battle  is  a  complex  and  time-critical 
task.  It  is  of  considerable  practical  interest  to  understand  the  planning  and 
decision  making  processes  that  are  involved.  In  addition,  it  is  important  to 
determine  under  what  conditions  these  decision  processes  might  degrade  and 
what  might  be  done  to  supplement  them.  One  of  the  means  for  investigating 
human  decision  making  and  the  associated  planning  processes  is  to  devise  a 
simulation  environment  in  which  these  processes  can  be  made  to  occur  and 
thereby  studied.  Variables  of  interest  may  be  manipulated  and  their  results 
observed.  This  also  offers  a  cost  effective  method.  Consequently,  an  army 
wargame  facility  (WARFAC)  was  devised  at  DCIEM  through  the  1980’s  (1). 

WARFAC  is  a  multi-player,  land  based  tactical  wargame  that  can  be  run 
in  conjunction  with  anciUiary  cognitive  tasks  and  an  electrophysiological  data 
collection  and  analysis  system.  Each  player  is  in  command  of  a  division  of 
units  composed  of  tanks,  infantry,  heUcopters,  etc..  The  game  has  two  phases, 
combat  phase,  and  movement  phase.  In  the  combat  phase,  the  players  take 
turns  executing  attacking  and  defensive  fire.  In  the  movement  phase,  both 
players  may  submit  movement  orders  for  their  units.  The  WARFAC  system 
has  been  assessed  by  army  officers  to  be  capable  of  providing  some  of  the  essen¬ 
tial  features  for  the  study  of  army  command  and  control  (C^).  However,  since 
each  player’s  activity  results  from  as  yet  poorly  understood  decision  processes, 
the  combined  behaviour  of  the  players  can  be  highly  variable.  From  the  ex¬ 
perimenter’s  perspective,  this  is  undesirable  since  it  becomes  difficult  to  draw 
general  conclusions  about  how  either  human  player  is  operating. 

It  was  therefore  deemed  desirable  to  build  an  intelligent  computer  opponent 
(WFICO)  which  could  be  defined  in  terms  of  a  set  of  rules  for  game  play. 
Such  a  system  would  provide  a  consistent  opponent  and  thus  simphfy  the  task 
of  assessing  the  human  player’s  performance.  It  was  determined  that  rule- 
based  methods  would  provide  an  effective  approach  (2).  Figure  1  illustrates 
the  general  model  for  a  rule-based  expert  system. 

This  conclusion  was  based  on  the  observation  that  considerable  documen¬ 
tation  exists  for  battle  procedures  that  can  be  interpreted  in  condition-action 
format.  For  example.  Defensive  Operations  (3)  and  Land  Formations  in  Battle 

(4)  outline  defensive  maneuvers  in  sufficient  detail  that  rules  may  be  defined 
which  provide  for  the  deployment  of  forces.  Additionally,  rule-based  expert 
systems  have  the  virtue  of  supporting  an  incremental  and  modular  approach 
and  good  generic  expert  system  shells  exist  for  development  of  such  systems 

(5) .  Therefore,  we  designed  an  intelligent  computer  opponent  (WFICO)  with  a 
dynamic  knowledge  base,  inference  engine  (2)  and  multiple  levels  of  rules  that 
model  the  hierarchy.  This  report  details  the  status  of  this  expert  system, 
the  shell  used  in  its  development,  and  the  potential  of  the  expert  system  as  a 
research  tool. 


3  The  Intelligent  Computer  Opponent 


3.1  Hardware  Requirements 

WARFAC  runs  on  a  DEC  VAX  minicomputer.  The  players  sit  at  Commodore 
Amiga  microcomputers,  which  provide  a  graphical  user  interface  to  the  game 
based  on  map  displays.  The  Amigas  also  provide  automated  data  collection 


Expert  System  Schematic.  An  expert  system  (ES)  consists  of  a  set  of  functional  units  which 
operate  to  provide  an  interactive  symbolic  problem  solving  partner  to  a  human.  As  a  dialog  the  interac¬ 
tion  includes  mutual  requests  for  information  between  the  human  and  the  ES.  In  addition,  the  ES  may 
be  requested  to  explain  its  reasoning  processes.  The  focus  of  the  dialog  is  maintained  within  the  ES  by 
a  working  memory.  A  knowledge  base  maintains  a  set  of  facts  and  rules  of  inference  about  the  domain 
of  expertise.  The  inference  engine  contains  a  set  of  inferencing  control  functions  (e.g,,  backward  and 
forward  reasoning  functions)  which  access  known  facts  and  rules  and  deduce  new  ones. 


Figure  1: 
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WFICO  System  Configuration 


Figure  2:  Hardware  and  Software  Configuration.  The  wargame  proper  (WARFAC) 
runs  on  a  VAX,  the  user  Map  Processors  (MAPPROC)  run  on  Amigas,  and  the  Fake 
Map  Processor  (FMP)  and  Intelligent  Computer  Opponent  (ICO)  run  on  a  SUN. 
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for  ancilliary  cognitive  tasks  and  electrophysiological  recordings,  if  desired. 
WFICO  runs  on  a  SUN  workstation.  The  VAX,  SUN  and  Amigas  are  net¬ 
worked  together  by  Ethernet.  The  logical  connections  are  shown  in  Figure  2. 
In  the  figure,  the  SUN  is  shown  interposed  between  the  VAX  and  an  Amiga. 
To  the  VAX,  the  SUN  running  WFICO  is  indistinguishable  from  an  Amiga 
with  a  human  player.  WFICO  can  optionally  pass  game  information  on  to  an 
Amiga  with  map  displays  as  a  debugging  aid.  In  the  future,  this  passthrough 
capability  could  be  used  to  provide  an  expert  advisor  for  a  human  player  (see 
section  5.2). 

3.2  Software  Components 

A  user  interfaces  with  WARFAC  through  a  map  processor  (MAPPROC)  that 
runs  on  an  Amiga.  For  WFICO  a  fake  map  processor  (FMP)  was  designed  to 
act  as  the  interface  between  WARFAC  and  the  Intelligent  Computer  Opponent 
(ICO).  The  FMP  emulates  the  Amiga  Map  Processor  interface  to  the  VAX  and 
isolates  the  ICO  from  the  details  of  communicating  with  WARFAC.  Within  the 
ICO  there  is  a  further  distinction  between  rules  that  model  the  hierarchy 
and  lower  level  rules  specific  to  WARFAC.  The  next  two  sections  describe  the 
FMP  and  ICO  in  detail. 


3.3  The  Fake  Map  Processor  (FMP) 

The  FMP  contains  C  language  data  structures  and  code  essentially  identical  to 
parts  of  the  Map  Processor  program  that  runs  in  the  Amiga  display  stations. 
It  builds  a  local  copy  of  the  information  it  is  sent  about  the  world.  While  the 
Amiga  map  processor  presents  this  information  graphically  to  a  human  player, 
the  FMP  presents  it  to  the  ICO  in  the  form  of  structured  data  objects.  It  also 
contains  code  to  initialize  the  ICO  and  to  start  inferencing.  The  Amiga  map 
processor  accepts  commands  that  the  player  enters  by  clicking  with  a  mouse, 
and  sends  them  to  the  wargame.  The  FMP  does  the  same  with  command 
messages  from  the  ICO. 

The  FMP  receives  messages  from  the  wargame  on  the  VAX,  updates  its 
own  data  structures  as  well  as  the  ICO’s  knowledge  base,  and  initiates  infer¬ 
encing  by  the  ICO  when  appropriate.  For  example,  when  the  wargame  sends  a 
“UNIT  JNFO”  message  to  the  FMP,  the  FMP  updates  the  information  it  has 
on  that  specific  unit,  then  updates  the  ICO’s  representation  of  the  unit.  No 
inferencing  by  the  ICO  is  required.  When  the  wargame  sends  a  “MOVE”  mes¬ 
sage  to  the  FMP,  the  FMP  does  not  have  to  update  any  of  its  data  structures, 
but  does  initiate  inferencing  by  the  ICO  for  the  movement  phase.  When  the 
FMP  receives  a  command  message  from  the  ICO,  for  example,  a  list  of  units 
to  be  moved  to  a  new  map  location,  it  translates  it  into  the  WARFAC  message 
format  and  passes  it  on. 

The  FMP  has  provision  for  a  pass-through  mode  where  it  sends  messages 
from  the  wargame  to  both  the  ICO  and  an  Amiga  display  station  (dashed  line 
in  Figure  2).  In  this  mode,  commands  from  the  ICO  are  sent  to  the  display  of 
the  SUN  only,  and  not  back  to  the  wargame.  A  human  player  at  the  Amiga  may 
then  consider  the  action  the  ICO  would  have  performed  as  a  recommendation 
when  deciding  on  an  action.  With  some  embellishment  of  the  user  interface 
and  explanation  facilities,  this  could  serve  as  the  basis  for  a  tactical  advisor  to 
a  human  player  (this  concept  is  further  discussed  in  section  5.2). 
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3.4  Intelligent  Computer  Opponent 

The  ICO  is  a  knowledge  based  system  written  in  the  “Nexpert  Object”  (6) 
expert  system  shell.  It  consists  of  declarative  knowledge,  in  the  form  of  classes 
and  objects,  which  represents  such  things  as  infantry  units  and  subdomain 
expert  state  information,  and  procedural  knowledge,  in  the  form  of  rules,  that 
express  actions  such  as  when  a  unit  should  fire.  The  ICO  has  a  model  of 
the  “world”  of  the  game  that  constitutes  its  environment,  and  a  hierarchy  of 
command  and  control  that  models  the  flow  of  orders  and  information  through 
the  chain  of  command. 

3.4.1  Nexpert  Object 

Nexpert  Object  is  an  expert  system  development  environment  that  runs  on 
many  different  hardware  platforms.  It  is  used  at  DCIEM  on  both  SUN  work¬ 
stations  and  Macintosh  microcomputers.  It  provides  graphically  based  devel¬ 
opment  tools,  and  allows  easy  integration  with  components  of  a  system,  such 
as  the  FMP,  that  are  better  suited  to  implementation  in  a  lower  level  language, 
such  as  C. 

Nexpert  allows  knowledge  to  be  represented  as  object  oriented  hierarchies 
of  classes  and  objects.  For  example,  in  the  ICO  there  is  a  class  named  “unit” 
with  an  instantiated  object  for  each  tank,  helicopter,  etc.,  in  the  game.  Rea¬ 
soning  is  expressed  in  logical  inferencing  rules  that  operate  on  these  objects. 
The  ICO  contains  rules  such  as  “If  a  unit  is  disrupted  then  it  can’t  move.” 
The  Nexpert  inferencing  engine  is  very  flexible  and  powerful,  allowing  multiple 
inferencing  strategies  to  be  used  simultaneously.  In  the  interest  of  simplifying 
the  design  and  enhancing  maintainability,  we  chose  an  exclusively  backward 
chaining  inferencing  paradigm  (7)  for  the  ICO. 

3.4.2  ICO  Command  and  Control  Hierarchy 

The  ICO  is  structured  as  a  set  of  separate  subdomain  experts  that  commu¬ 
nicate  through  a  chain  of  command  (8).  All  orders  start  at  the  Division  level. 
The  Division  commander  (DIV)  passes  orders  down  to  a  Brigade  commander 
(BCD).  The  Brigade  commander  in  turn  passes  orders  down  to  subdomain 
experts  such  as  Intelligence  (INT),  Operations  (OPS),  and  Logistics  (LOG). 

Each  subdomain  expert  consists  of  a  domain  specific  set  of  knowledge  struc¬ 
tures  and  inferencing  rules.  These  in  turn,  are  built  up  from  a  number  of  lower 
level  structures  and  rules.  At  the  lowest  levels  (below  the  dashed  line  in  Figure 
3)  there  are  knowledge  structures  and  rules  specific  to  the  wargame..  These 
pertain  to  such  things  as  who  can  fire  on  whom,  when  units  may  fire,  and  how 
they  fire.  These  are  used  by  the  various  subdomain  experts  such  as  OPS  when 
carrying  out  their  orders.  OPS  has  rules  for  performing  two  types  of  defensive 
fire:  pre-emptive,  where  the  opponent’s  offence  is  anticipated;  and  reactive,  in 
response  to  direct  attacks  by  the  opponent.  These  rules  send  orders  to  Artillery 
for  indirect  fire,  and  request  unit  movement  required  for  battle  management. 

Inferencing  follows  the  chain  of  command.  For  example,  when  the  ICO 
gets  a  “move”  message  from  the  FMP  indicating  that  the  wargame  is  in  the 
movement  phase,  the  ICO  Division  commander  gives  a  movement  order  to 
the  Brigade  commander.  The  Brigade  commander  gives  a  movement  order 
to  Intelligence  and  to  Operations.  Intelligence  requests  any  unit  movements 
required  for  surveillance  purposes.  Operations  requests  any  unit  movements 
for  battle  management.  After  resolving  all  movement  requests,  the  Brigade 


Figure  3:  Command  and  Control  flows  down  this  graph.  Division  and  Brigade  com¬ 
mand,  and  the  subdomain  experts  are  above  the  dashed  line.  Below  the  dashed  line 
are  lower  level,  WARFAC  specific  rules. 


commander  gives  a  movement  order  to  Logistics.  Logistics  is  responsible  for 
carrying  out  the  movements. 

The  current  Intelligence  subdomain  expert  does  not  request  unit  move¬ 
ments,  so  the  Brigade  commander  has  no  conflicting  requests  to  resolve.  It 
is  proposed  that  requests  from  midtiple  subdomain  experts  could  be  resolved 
by  combination  along  the  lines  suggested  in  Ling  and  Rudd  (9).  They  define 
formulae  for  combining  numerical  representations  of  expert  opinions  that  may 
have  stochastic  dependencies. 

3.5  Current  Implementation 

Nexpert  permits  an  incremental  development  of  the  rule  base.  Thus,  a  working 
prototype  with  increasing  degrees  of  sophistication  could  be  developed.  Since 
one  of  the  motivations  for  building  this  system  was  that  it  should  model  human 

decision-making,  the  ICO  had  access  only  to  data  that  a  human  player  could 
acquire.  For  example,  the  locations  of  only  those  enemy  units  (i.e.,  the  human’s 
units)  that  would  be  visible  on  an  Amiga  map  display.  The  ICO  had  no  priv¬ 
ileged  access  to  WARFAC  data  structures.  WARFAC  specific  knowledge  and 
procedures  were  isolated  as  much  as  practicable,  in  the  interest  of  maximizing 
the  adaptability  of  the  expert  system  to  other  environments. 

The  working  prototype  at  the  time  of  this  document  is  an  ICO  with  defensive 
capabilities.  Rules  for  offensive  moves  (which  take  an  initiative  to  attack  and 
obtain  a  high-level  objective)  were  not  implemented,  although  this  could  be 
done  in  future  versions.  The  scenario  that  has  been  used  to  test  the  ICO 
is  the  defence  of  a  bridge  against  an  attacking  force.  In  the  bridge  defence 
scenario,  the  WFICO’s  forces  start  in  defensive  position  around  a  bridge.  The 
ICO  rule  set  wiU  attempt  to  maintain  possession  of  the  bridge.  Briefly,  it  does 
this  by  holding  the  position  of  its  units.  If  a  unit  is  attacked  and  repelled 
from  a  position,  the  WFICO  attempts  to  regain  the  position.  Defensive  fire  is 
concentrated  on  attacking  units  that  are  deemed  to  pose  the  greatest  threat. 
This  threat  level  is  measured  by  the  cumulative  amount  of  damage  that  has 
previously  been  inflicted  on  friendly  forces  by  each  attacking  unit.  If  necessary, 
units  wiU  move  into  new  positions  to  bring  fire  against  the  attacking  units  that 
pose  the  greatest  threat.  This  movement  is  only  done  within  constraints  that 
maintain  the  units  being  moved  in  a  defensive  position  about  the  bridge. 

The  initial  set  of  knowledge  structures  in  the  ICO  is  quite  small.  This  num¬ 
ber  grows  dynamically  over  the  course  of  a  game,  for  example,  as  new  enemy 
units  axe  detected.  The  ICO  currently  contains  approximately  one  hundred 
rules.  Rule  development  was  focused  on  the  Operations  subdomain  expert.  It 
contains  the  majority  of  the  high  level  rules  in  the  system.  Most  of  the  rules 
are  lower  level,  game  specific  rules  (below  the  dashed  line  in  Figure  3)  that 
support  those  higher  ones.  Figure  4  shows  a  partial  set  of  the  higher  level  rules 
contained  in  the  Operations  subdomain  expert  that  are  used  to  move  defending 
units  in  response  to  a  threat.  The  inferencing  subtree  containing  the  rules  in 
Figure  4  is  shown  in  Figure  5. 


The  ICO  only  uses  partial  knowledge  of  unit  characteristics  (e.g.,  it  does 
not  consider  which  weapons  and  sensors  an  enemy  unit  has),  and  does  not  yet 
incorporate  terrain  knowledge  when  it  is  considering  movement.  The  addition 
of  this  knowledge  could  enhance  the  defensive  abilities  of  the  ICO,  and  would 
likely  be  essential  for  a  sophisticated  offensive  capability.  The  FMP  currently 


RULE  :  Rule  67 
If 

ops. orders  is  "movement" 

And  there  is  evidence  of  ops_movement J.nit_threat 
And  there  is  no  evidence  of  ops  .movement  .threat 

Then  opsjnovement 

is  confirmed. 

RULE  :  Rule  107 
If 

ops. orders  is  "movement" 

And  there  is  evidence  of  ops jnovement .set .threat 
And  there  is  evidence  of  opsjnovement J.nitjnoving 
And  there  is  no  evidence  of  ops  jnovement  jnoving 

Then  ops  jnovement  .threat 

is  confirmed. 

And  Delete  Object  ^unit ' \threat  jmitJLd\  lunits.threat.c  I 
And  Reset  ops  jnovement  .threat 

RULE  :  Rule  102 
If 

ops. orders  is  "movement" 

And  there  is  evidence  of  ops  jnovement  .set  jnoving 
And  there  is  evidence  of  ops  jnovement  jnove 

Then  ops  jnovement  jnoving 

is  confirmed. 

And  Delete  Object  'unit  ^ \move  Jinit  J.d\  |units.unmoved_c  | 
And  Reset  ops  jnovement  jnoving 

RULE  :  Rule  100 
If 

ops. orders  is  "movement" 

And  there  is  evidence  of  ops  Jnovement  .calc  ji 
And  there  is  evidence  of  opsjnovement.calc_R 
And  there  is  evidence  of  opsjnovement.calcJ)CE 
And  there  is  evidence  of  ops  jnovement  .cal  cJ)UE 
And  DUE-R  is  greater  than  0 

And  DCE-CEIL(R+R/n)  is  less  than  or  equal  to  0 
And  there  is  evidence  of  ops  jnovement  .cal  c_T 

Then  opsjnovement  jnove 

is  confirmed. 

And  Tx  is  assigned  to  'unit ' \movejinitJ.d\ .wannabe jc 
And  Ty  is  assigned  to  'unit ' \movejinitJ.d\ .wannabe. y 


Figure  4:  Some  Battle  Management  Movement  Rules 


ops. orders  Is 
Yes  ops_jnovement_cjs^ 
Yes  ops_movement_cj- 
Yes  ops_moveMent_c*^ 
DCE-CElL<R+R/n>  >  </ 

ops. orders  Is  "tnovsy^ 
Yes  opsj>towei»ent_c*^ 
Yes  ops_jfloveinent_c*^ 
DUE-R  <=  0/ 

ops. orders  Is  "movt 
Yes  ops_p»ovenient_c« 
Yes  ops_jnoweroent..c»Ji 
Yes  ops_(nowement_c»^^ 
Yes  opsjnovenient_cv., 
DUE-R  >  0^ 
DCE-CEIL<R*R/n>  <=  / 
Yes  ops_moveinent_c/fl 
=>Do  Tx  'unit'Sinouw 
=>Do  Ty  'unit'^ovr 


)  ops. orders  Is  "mow*^ 
Yes  opsjnovefnent_s*,^ 
Yes  ops_inovnnent_pic- 
=:>DeleteObJect  'unJ^ 
=> Reset  ops_jnoveinei^ 

ops. orders  Is  "tnovs^ 
Yes  op8_mowement_s<.y 
Ho  ops_rnovement_r)Ow 
=>DeleteObJect  'un>^ 
=>  Reset  opsjnov  enter 


ops.  orders  Is  "tnovs 
Yes  ops_ntove!nent_s«A 
I  Yes  opsjnovCTtent_lr>^ 
iNo  ops_movewent_mov^ 
=>DeleteObject  'un*7 
=>Reset  op s_moy enter 


ope, orders  Is  “mov«. 

Yes  aps_friove«ertt_lr— ^r 
r.l07 — No  ops_/itowentent_tht/ 

ops. orders  Is  “ntov«^,_^ 
No  ops_inovefltent_lni''^ 


Figure  5:  Partial  Inferencing  Subtree  for  rules  in  Figure  4. 


accepts  all  types  of  messages  that  can  be  sent  from  the  wargame^.  Many  of 
these  messages  contain  potentially  useful  information  that  the  ICO  does  not 
presently  extract  or  take  advantage  of. 

3.6  Evaluation 

Even  with  a  small  base  of  partial  world  knowledge  and  very  simple  rules  govern- 
ing  fire  and  movement,  the  ICO  is  able  to  respond  well  enough  to  enemy  attacks 
to  provide  a  reasonably  challenging  opponent  to  a  sophisticated  attacker. 

Figure  6  shows  a  closeup  of  the  ICO’s  units  in  their  initial  position  around 
the  bridge  (The  vertical  line  at  map  a;  =  31  is  a  river,  shown  in  blue  on  the 
colour  display,  the  other  lines  are  roads,  shown  in  black).  When  an  enemy  unit 
comes  within  sensing  range,  the  ICO  determines  whether  any  of  its  units  can  be 
moved  into  position  to  fire  upon  the  enemy  unit,  while  stiU  keeping  the  bridge 
within  their  range  of  fire. 

Figure  7  shows  the  position  from  Figure  6  after  the  ICO  has  moved  artillery 
units  towards  a  threat,  the  enemy  units  off  to  the  right.  The  artillery  units  have 
moved  so  the  enemy  units  are  just  inside  the  rightmost  limit  of  their  range.  If 
an  enemy  unit  in  another  location  becomes  a  greater  threat,  the  artillery  will 
be  redeployed,  provided  it  is  not  pinned  down  by  enemy  fire,  and  it  is  capable  of 
moving.  Attacking  units  are  considered  to  be  greater  threats  once  they  attack 
defending  units  of  high  value,  such  as  a  headquarters.  The  ICO  prioritizes 
pre-emptive  defensive  fire  to  attack  the  highest  threats  first. 

The  level  of  play  provided  by  the  rules  in  the  ICO  is  sufficient  to  require 
careful  planning  by  the  attacker  to  defeat  the  defending  force.  This  has  been 
accomplished  by  an  experienced  human  player  in  about  one  hour  of  playing 
time,  starting  with  a  small  force  equal  in  size  and  capability  to  the  defending 

^Over  one  hundred  message  types. 
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Figure  7:  The  position  from  Figure  6  after  responding  to  the  threat  posed  by  the 
enemy  units  to  the  right. 


force. 


4  Nexpert  Object  as  a  tool 

While  Nexpert  Object  has  proved  an  adequate  tool  for  implementation  of  this 
project,  some  limitations  in  it  have  become  evident.  The  WFICO  was  imple¬ 
mented  using  version  1  (6)  of  Nexpert  Object.  Features  have  been  improved 
and  added  in  version  2,  but  these  limitations  are  still  present.  The  implemen¬ 
tation  of  object  oriented  knowledge  structures  is  limited.  Objects  reside  in  a 
global  name  space,  making  encapsulation  and  data  hiding  awkward  at  best,  and 
the  structure  that  objects  can  have  is  fairly  limited.  These  limitations  can  be 
mitigated  by  using  external  routines  for  representing  and  manipulating  parts 
of  the  knowledge  base. 

The  inferencing  engine  of  Nexpert  is  excellent.  The  graphically  based  devel¬ 
opment  environment  provides  advantages  for  overviewing  and  debugging  small 
sets  of  rules.  However,  as  the  ICO  grew  larger  than  a  few  dozen  rules  and 
objects,  the  development  tools  rapidly  became  rather  awkward  to  use.  Moving 
through  the  entire  knowledge  base  to  find  and  edit  specific  rules  and  objects 
became  a  repetitive  and  time  consuming  task.  While  Nexpert  does  provide  for 
splitting  projects  into  multiple  separate  knowledge  bases,  this  strategy  causes 
forward  reference  problems  and  is  best  either  used  sparingly  or  avoided  entirely. 
In  comparison,  all  the  generic  expert  system  shells  have  limitations  with  respect 
to  any  specific  project.  These  must  be  weighed  against  the  costs  inherent  in 
developing  a  custom  environment  using  a  more  general  purpose  programming 
language. 


5  Uses  of  WFICO 

5.1  Assessment  of  Human  Decision  Processes 

A  simulation  of  army  warfare  provides  a  medium  for  the  study  of  decision  pro¬ 
cesses  involved  in  Clearly,  the  scope  of  thinking  and  behaviour  that  can  be 
assessed  wiU  depend  on  the  realism  and  level  of  detail  of  the  simulation.  The 
WARFAC  and  WFICO  opponent  provide  a  basis  for  the  study  of  high-level 
decision  processes;  those  processes  that  are  concerned  with  the  unfolding  in 
space  and  time  of  a  combat  scenario.  The  WFICO,  as  a  configurable  opponent 
that  wiU  behave  consistently  in  meeting  a  human  challenger,  permits  a  system¬ 
atic  study  of  these  high-level  decision  processes.  In  this  context  the  following 
questions  could  be  addressed  through  experiment: 

1.  What  is  the  relationship  between  the  size  of  the  forces  and  the  time  re¬ 
quired  to  make  effective  use  of  them? 

2.  How  do  the  decision  processes  differ  between  the  deployment  of  forces  and 
the  use  of  those  forces  once  they  are  deployed? 

3.  How  can  a  “good”  plan  be  recognized  and  evaluated? 

4.  How  do  time  pressure,  fatigue  and  other  stress  inducing  factors  affect  the 
decision  making  processes? 

While  such  questions  may  be  easily  posed,  it  becomes  a  challenge  to  deter¬ 
mine  how  human  performance  might  be  measured  to  find  reasonable  answers. 
Thus,  performance  measurement  becomes  a  major  issue  in  designing  a  specific. 
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experiment.  In  the  current  state  of  WARFAC,  only  a  few  performan.ce  mea¬ 
sures  are  accessible:  the  number  of  turns  of  play  it  takes  to  reach  an  objective, 
the  time  taken  by  the  human  player  in  each  game  phase  and  the  status  of  the 
forces  (unit  parameters  such  as  strength).  The  physiological  state  of  the  player 
can  also  be  monitored  and  associated  with  specific  actions  and  game  states. 

Future  work  with  WARFAC  will  involve  the  determination,  for  the  partic¬ 
ular  experiment  of  interest,  of  performance  measures  that  could  be  built  into 
the  system.  These  may  be  divided  into  two  sets:  outcome  measures  and  pro¬ 
cess  measures.  Outcome  measures  could  include  points  lost  on  either  side,  the 
total  time  taken,  and  whether  the  objective  was  (or  was  not)  achieved.  Such 
measures  tend  to  be  global  in  nature  and  are  likely  to  be  uninformative  about 
the  decisions  that  were  made  during  the  wargame. 

Process  measures,  on  the  other  hand,  assess  ongoing  decision  processes  as 
the  wargame  progresses.  These  types  of  decisions  wiU  likely  require  measures 
to  be  computed  and  stored  dynamically  as  they  occur.  Planning  processes  are 
often  difficult  to  assess  since  they  are  largely  non-verbalized  mental  activities. 
A  medium  for  expressing  and  thus  recording  mental  processes  would  help  in  un¬ 
derstanding  why  particular  decisions  were  made,  as  the  plan  provides  context. 
A  review  of  division-level  command  and  control  (10)  discusses  these  issues  and 
provides  a  basis  for  designing  measures  that  could  be  of  use  with  WARFAC. 

5.2  Assisting  the  Human  in  a  Decision  Task 

The  WFICO  has  been  designed  to  play  against  another  player.  However,  pro¬ 
vision  was  made  in  the  design  for  adding  a  WARFAC  advisor  mode,  where  the 
expert  system  would  suggest  actions  to  a  human  player  rather  than  playing  di¬ 
rectly.  This  allows  the  possibility  of  computer  assisted  game  play.  The  WFICO 
would  sit  between  the  wargame  and  the  human  player  at  an  Amiga  worksta¬ 
tion,  and  monitor  game  messages  and  player  responses.  Before  performing  an 
action,  the  player  would  turn  to  the  WFICO  to  see  what  action  it  recommends. 
The  player  would  be  able  to  ask  the  WFICO  why  it  would  perform  a  particular 
action,  before  deciding  whether  to  accept  its  recommendation.  The  WFICO 
would  be  able  to  detect  when  the  player’s  response  was  different  from  its  own. 
Differences  could  prompt  a  query  to  the  player  as  to  why  the  move  was  being 
made,  and  the  answer  could  be  recorded. 

There  is  also  the  possibility  of  using  the  advisor  mode  in  conjunction  with 
machine  learning  techniques,  to  allow  the  WFICO  to  move  its  own  decision 
model  towards  the  behavior  exhibited  by  the  human  player.  This  could  be 
done  by  using  knowledge  of  the  conditions  (state  of  the  world)  and  the  action 
performed  to  create  a  new  rule  for  the  knowledge  base.  A  model  of  how  a 
particular  human  player  is  making  decisions  could  be  built  up  in  an  incremental 
manner.  The  display  capabilities  of  Nexpert  would  allow  this  model  to  be 
shown  as  a  condition- action  graph.  The  ability  to  create  new  rules  for  dynamic 
addition  to  a  knowledge  base  is  a  substantive  task  as  it  requires  that  each 
new  rule  be  checked  for  consistency  with  the  existing  knowledge  base,  and  an 
appropriate  place  for  its  insertion  must  be  determined. 

The  addition  of  a  simple  advisor  mode  would  be  primarily  a  matter  of  en¬ 
hancing  the  existing  user  interface,  which  is  intended  as  a  debugging  aid  for 
the  WFICO  developer.  A  rudimentary  explanation  facility,  allowing  the  player 
to  scan  backwards  through  the  sequence  of  rules  that  led  to  the  current  recom¬ 
mended  action,  cotdd  be  done  easily  using  the  built  in  explanation  capabilities 
of  Nexpert.  To  explain  higher  level  motivations,  and  bypass  long  chains  of 
trivial  rules,  a  more  elaborate  explanation  facility  would  have  to  be  designed. 
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This  would  be  a  significant  undertaking,  ajid  is  an  area  of  active  research  (11). 


5.3  Testing  Decision  Making  Rules 

Like  machine-based  chess  players,  the  WFICO  could  be  played  against  itself. 
Of  course,  in  its  current  implementation  it  is  not  well  suited  to  this  as  it  is 
a  purely  defensive  player.  However,  if  an  offensive  component  were  developed 
then  it  would  be  possible  to  test  rules  of  decision  making  in  machine  on  machine 
wargames.  In  such  an  environment,  problems  could  be  identified  and  decision 
processes  refined  in  a  cycle  of  development.  Not  only  might  this  produce  a 
better  game  player,  but  it  could  provide  insights  into  more  general  decision 
processes.  The  validity  of  such  an  exercise  would  depend  upon  the  realism  of 
the  scenario  being  simulated  with  WARFAC. 
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7  Glossary 

Backward  Chaining  Starting  with  a  goal,  and  breaking  it  up  into  subgoals 
recursively  to  find  a  solution  to  the  initial  goal. 

Declarative  Knowledge  Information  that  is  expressed  as  a  fact.  E.g.,  The 
cow  is  purple.  Declarative  knowledge  may  be  generated  from  procedural 
knowledge. 

Expert  System  A  computer  program  designed  to  solve  problems  in  a  re¬ 
stricted  domain. 

Expert  System  Shell  A  specialized  programming  language  designed  for  im¬ 
plementing  expert  systems  for  arbitrary  restricted  domains. 

Inference  Engine  A  computer  program  that  operates  on  sets  of  logical  rules 
according  to  one  or  more  control  strategies,  such  as  backwards  chaining. 

Knowledge  Based  System  A  computer  program  that  works  with  declara¬ 
tive  and  procedural  information  to  solve  problems.  Expert  systems  are 
often  knowledge  based. 

Object  Oriented  Encapsulated  classes  and  objects  that  are  able  to  inherit 
properties  from  each  other  according  to  an  inheritance  hierarchy. 

Procedural  Knowledge  Information  that  is  represented  as  a  rule  or  set  of 
rules,  that  may  be  used  to  generate  new  rules  and  declarative  knowledge. 

Production  System  A  computer  program  incorporating  an  inference  engine 
and  a  set  of  rules  and  data.  An  expert  system  can  be  a  knowledge  based 
production  system. 

Subdomain  Expert  An  expert  system  component  with  a  domain  of  reason¬ 
ing  that  is  restricted  to  a  specific  area  within  the  problem  domain. 
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